Thread: reborn and jv-bots ?

You wouldn't want a dirty one like mine

Originally Posted by own3mall

I disagree. You're not helping at all with that attitude. If someone knows how to do something better than someone else, that person should be consulted on what needs to be done. You don't just hand out code on a silver platter, but if you can explain the process while demonstrating the commands that need to be used, that's the most helpful approach. In any case, finding much information regarding JV Bots in this day and age is extremely hard to come by. I can't figure out the way to use what JV has in version 1 to make the bots fight as they do in the POC. To me, JV Bots would be acceptable if the bots would randomly lean and jump. I think there's something wrong with the pathnodes that eaglear setup in his dm maps... some bots stop moving and camp no matter the priority set, and yes I've removed anything that might overwrite the new cvar settings usage.

In either case, I have created a complete JV Bots release that I will be posting on the forums in the next couple of days. This version now uses cvars to set priority and difficulty, or defaults to better values if they're not used. I've combined JVBots1, JVBotsUpdate1, jvbot xtra (your mod), eaglear's dm maps implementation, and Cheech's obj maps all into one PK3. Cheech's obj maps work pretty well. Its ridiculous that everything jv did was separated into multiple files and never received a n00b friendly release.

I'll see if I can come up with anything, but no matter how long I look at both code samples, I still am no MOHAA script expert. This is why I need help. I like your ideas about smarter bots, but I'm just being realistic here. We need something acceptable until something else can (if ever) be made.

It doesn't help that I had to go out hunting for all of these files to begin with.....

In my opinion, if the POC fight system (minor tweaks... bots shouldn't be hiding behind walls leaning and looking at each other waiting for the other bot to come into their line of fire... they both just lean and wait looking at each other through walls lmfao) could be implemented into JV Bots so that they still use their task priorities until a fight happens, we'd have acceptable bots. Unfortunately, I don't think I'm the person to do this...

Again, I don't understand, why would it be 'n00b'-friendly? Why do you refuse to accept that this software subject and its implementation is just complicated by nature?
Why do you refuse the accept one of the fundamental rules of logic which clearly states that you need to understand a problem before you can think about solving it?

Also all forum posts discussing bots, jv_bots etc... on mods-r-us, .map, tmt etc... are still there the last time I checked. And you have the source code. Information aplenty, I reckon.
I really want to help you, but it seems you're dead set on looking at as little source code and research as possible, so I don't know if I'll be of much help (besides offering quick fix-me's).

I'm not trying to be the bad guy here. So if you honestly can't find how jv makes the bots lean, then I shall tell you.

First: the observations:
-> leaning is an animation
-> "cueued_upperanim" also refers to animation
-> you realize the answer isn't located in the fight.scr script
-> however there is one script called 'anim.scr' which is the only one that appears to refer to animation or movement
-> you also remember some obnoxious guy on xNULL telling you to look in the script you don't want to look at:
-> anim.scr is the largest script
-> at first glance it also seems the most complicated
-> if that guy was on to something, then he is referring to this script.

Second: searching:
Based on your previous observations, you open anim.scr as it seems the most likely to contain the line of code you're seeking
-> What am I searching again? Oh yes, something about leaning. I know a property called 'lean_angle' is used in the fight.scr
and it seems logical to try searching first
-> CTRL+F and find 'lean'
-> first result is found in the 'misc_controller' thread of the script:

Code:

            // force no lean
            local.lean = 0

A few instructions further the 'lean_angle' (the one you were seeking) is not being used, but only being calculated here.
We can skip all matches in this thread.
-> next result is found in the 'upperanimhandler' thread:

Code:

// lean angle must be reduced before doing an upperanim

Hm, wasn't there something about upperanimations in fight.scr?
-> Just a few lines below it we have

Code:

            // set controllerangles just for fun
            self setcontrollerangles 1 (self.pitch 0.0 self.lean_angle)
            
            // set a dummy anim
            // so setcontrollerangles can be used
            // this anim doesn't actually play
            self upperanim rifle_stand_idle
            self waittill upperanimdone

Aha, "setcontrollerangles"! So it sets angles and it uses the lean_angle property! Piece of code found!

Actually, you might have seen this before (I know you have, James):
http://www.modtheater.com/threads/mohaa-collision-script.33978/#post-312480

Now, I didn't write all the other stuff for fun. Take note and change your methods of scanning, it may save you a lot of precious hours in the long run.

Apparently 'setcontrollerangles' does work if you play a dummy animation on it first. Though, for players this gets quickly overridden because... well they're people
The bot will wait until the animation is done before it'll play its automatic animations. So jv used this behaviour so 'setcontrollerangles' could do its thing undisturbed.

@own3mall: for jumping, it's a bit more complicated:

Code:

        else if(self.key_jump && level.time - local.last_landing_time >= level.bots.jump_interval && self sighttrace self.origin (self.origin + (0 0 level.bots.JUMP_HEIGHT)) 0 level.bots.jumpbbox_mins level.bots.jumpbbox_maxs)        {            
            // check if we have room to jump
            // must go to idle anim before we can jump properly
            self setmotionanim (local.wtype + "_stand_idle")
            waitframe
            
            if(isAlive self)
            {
                // mice! eek! jump
                
                // jump up
                self pusher $world self $world.upvector level.bots.JUMP_HEIGHT
                self setmotionanim (local.wtype + "_jump_takeoff")
                waitframe
                
                if(isAlive self)
                {
                    // jump in pref. direction
                    self pusher $world self self.botmovedir level.bots.JUMP_DISTANCE
                    self waittill flaggedanimdone
                }
            }
        }

Although for initial tests, just use the 'pusher' instruction (it performs the actual jump) and tweak it accordingly.
"Pusher" just pushes the entity upward a specified distance. Actors have "physics_on" by default so they'll come
back down as you'd expect in terms of physics. The second 'pusher' pushes the bot in a specific direction when
they're already in the air. Similar to what players have to do (JUMP+UP, LEFT, RIGHT...).

However, the current animation of the bot will not change. This is what the additional animation instructions are for,
so the entire procedure is visually accompanied by the correct animations. Version 1's AI is still engine-controlled, so
they may change their animation automatically but they may not.

But if it doesn't and you care about the animations, the landing part is a bit trickier:

Code:

        self.onground = !(self sighttrace self.origin (self.origin - (0 0 1)) 0 level.bots.bbox_mins level.bots.bbox_maxs)
        
        // check if falling
        if(!self.onground)
        {
            if(!local.die_on_landing && self.velocity[2] <= level.bots.CRATER_SPEED)
            {
                // normally an error, but
                // some servers may have this aliased
                self playsound snd_fall
                
                local.die_on_landing = 1
            }
            
            // yup, falling
            // some of the anims don't loop properly, so always use smg anim
            self setmotionanim smg_fall
            waitframe
        }
        else if(local.die_on_landing)
        {
            // crater
            if(self)
            {
                self killed self 10000 $world (0 0 0) (0 0 0) (0 0 0) 0 0 7 0
            }
            break
        }
        else if(!local.wasonground)
        {    
            // land
            if(self.pose == level.bots.POSE_STAND && self.botmovedir == (0 0 0))
            {
                self setmotionanim (local.wtype + "_land")
                self waittill flaggedanimdone
            }
            else
            {
                // only play land anim when standing
                // but have to wait anyway to get wasonground set properly
                waitframe
            }
            local.last_landing_time = level.time
        }

This second part should probably be looped like in the original in anim.scr. It plays the correct animations when the bot is falling back down and handles the part where he lands or craters.

Thanks Sor & James. That information helps, A LOT.

@Sor
I find it funny that I searched and looked at the code using exactly the same method you described (exactly the same steps, and I saw all of the code you did regarding leaning and jumping). Unfortunately, the comments are rather lacking (developers suck at this... I like to comment almost every line especially if it's complicated...), and I don't understand the parameters that are passed to each one of these built in functions or how these functions actually work. I am actually using setcontrollerangles in my test version of JV Bots, but it's currently not working either. I wasn't sure if setcontrollerangles would set the leaning, but I figured it would. As for jumping, I didn't understand what push does. Now I do! Thanks. Would velocity work on bots too?

And yeah, I actually looked at James' script too to help me reaffirm that leaning is done via setcontrollerangles. This is good because I think we're all on the same page. I realize the complexity of these bot scripts, but yes, since I didn't write the mod, I am trying to make it as simple as possible to get my changes in. I have a concept / idea to make the bots work better, so this is what I'm trying to do.

I use PSPad (http://www.pspad.com/) and global find and replace in files (scans all subdirectories to find search keys / even regex searches). Had I not discovered this wonderful searching tool, I would never be able to do my real software developer job dealing with insurance.

With this additional information, I'll continue to play around with my ideas. Thanks guys.

EDIT:

I mean seriously, these comments suck!

Code:

          // set controllerangles just for fun
           self setcontrollerangles 1 (self.pitch 0.0 self.lean_angle)
            
            // set a dummy anim
            // so setcontrollerangles can be used
            // this anim doesn't actually play

"Set controllerangles just for fun". Thanks for that wonderful comment... why not explain what set controller angles DOES.

Code:

// Sets angles for leaning

// Play a dummy animation and wait until it's finished so that the controllerangles will make the bot lean

Comments such as the ones above would really have helped me... and then again, before he sets controller angles, he uses an if statement to check and make sure the pitch (not looking at the code atm... may not be pitch... at work) is under 5 or something like that. In which case, it would play an animation without setting controllerangles... this is where I got so confused. I don't have a problem searching and finding code, but following it and understanding what it does is where things can get complicated.

Well... a clean code shouldn't have almost any comments. It should be just clean and self-explanatory. If it's not and you need to add a lot of comments, it CAN MEAN (doesn't have to) that the code is not clean. Also a lot of comments introduce regression to the code. Programmers forget to update comments and this creates even bigger mess.

I'd say - avoid comments and write clean, self-explanatory code. You can add a header comment to just give an overview of the source code file. Make function/method names long but meaningfull, and you should be able to live without comments. Comment only when it's very very necessary.

Isn't that really a more an issue of preference and style, rather than an issue of coding? You can try to name your variables as best you can but
if you're doing some complicated stuff (I mean not in terms of programming) that the reader doesn't know about, he won't understand either way.

If you add comments, then readers can skim through your code more easily. They don't have to scan every instruction to understand how you're
achieving whatever you said the code achieves in the summary comment. It's also easier to lose track of program flow without them.
With code bouncing from thread to thread these days, it is sometimes helpful that few useful comments can guide you through the detour.

Clean code doesn't mean it's good code. A bad programmer can write clean code. It also depends on your definition of 'clean'. For example, a few
strategically placed goto's associated with concise, descriptive labels can be more readable (besides being more efficient by a long shot,) than
bloated loops and nested loops with error flags and exit flags and what have you. In any case, they're pointless variables that need to be checked
almost every single iteration, when you already know in advance that they will only rarely or exceptionally be evaluated as true.

Too bad most people are brainwashed to believe goto is evil.

But then again this is all a matter of taste. Sometimes I feel the urge to us comments frequently, while at other times I notice I didn't comment a few hundred lines.

I think I've made some progress, but I'm at a point again where I need to learn more. I keep getting errors such as these:

Code:

^~^~^ Script Error: unknown animation 'rifle_stand_idle' in 'models/human/multiplayer_allied_2nd-ranger_captain.tik'
^~^~^ Script Error: unknown animation 'smg_fall' in 'models/human/multiplayer_german_waffenss_nco.tik'

I've never done any animation work, so I'm confused here as well. In JVBots1, I think he overwrote the animations, so these standard ones that are called in the poc won't work. Should I use the ones that are in use in jvbot1, or can I copy them over somehow?

I'm guessing these will also not work in jvbots1 (from the POC):

Code:

self setmotionanim (local.wtype + "_land")
self setmotionanim (local.wtype + "_stand_idle")
self setmotionanim (local.wtype + "_jump_takeoff")
self upperanim rifle_stand_idle

JV does seem to be using these quite a lot, but I'm not sure if these should be used for these dummy animations to make bots lean, strafe, and jump.

Code:

self setmotionanim (self.weapongroup + "_stand_alert_legs")
self setupperanim (self.weapongroup + "_butt")
self setupperanim (self.weapongroup + "_stand_alert")

Any ideas on what should be done next? Also, how do I see your bot scoreboard that came from your xtra mod? Is there a cvar that needs to be set?

It's the other way around actually. I think I've hinted this before but in version 3 (as well as version 2) jv overrides the Actor's model with a playermodel. An Actor needs
to be spawned with actor animations first, and then the new playermodel cuts off all AI/single player animations. Because of this, jv had to emulate all animations (really,
everything) and movement flow (cf. anim.scr). The result of this is that we get complete control over bot's movement and animation so jv could program them anyway he'd like, but
the main benefit is that by using playermodels, the bots are now fully server-side.

The latter has to do with how version 1 made the bots functional in multiplayer. Custom actor models use 'multiplayer_generic_human.tik' instead of 'new_generic_human.tik'
as include. The files in question define all animations for the model and thus the entity. The modified 'multiplayer_generic_human.tik' just omits some single player animations
and code that prevented the game's AI from functioning in multiplayer. However, custom tiki's and client-side modifications meant client-side actor models, so if you were
to join a server running version 1 without having the jv_bot files yourself, the bots would appear invisible to you.

You can't consolidate both approaches. It's either one or the other. All I can tell you is that it's probably going to be a pain to make version 1 use version 3's animation handler,
especially considering that the handler in question isn't even finished yet. It's a proof of concept after all. I'd recommend to leave it as it is. If you need to do something
event-based or occasional (like jumping or leaning), then you can invoke the necessary animations to gets those routines working.

It's your call.

It may be useful to know that the core loop for each bot is "jv_mp_ai.scr::botcontrol".

Originally Posted by Sor

It's the other way around actually. I think I've hinted this before but in version 3 (as well as version 2) jv overrides the Actor's model with a playermodel. An Actor needs
to be spawned with actor animations first, and then the new playermodel cuts off all AI/single player animations. Because of this, jv had to emulate all animations (really,
everything) and movement flow (cf. anim.scr). The result of this is that we get complete control over bot's movement and animation so jv could program them anyway he'd like, but
the main benefit is that by using playermodels, the bots are now fully server-side.

The latter has to do with how version 1 made the bots functional in multiplayer. Custom actor models use 'multiplayer_generic_human.tik' instead of 'new_generic_human.tik'
as include. The files in question define all animations for the model and thus the entity. The modified 'multiplayer_generic_human.tik' just omits some single player animations
and code that prevented the game's AI from functioning in multiplayer. However, custom tiki's and client-side modifications meant client-side actor models, so if you were
to join a server running version 1 without having the jv_bot files yourself, the bots would appear invisible to you.

You can't consolidate both approaches. It's either one or the other. All I can tell you is that it's probably going to be a pain to make version 1 use version 3's animation handler,
especially considering that the handler in question isn't even finished yet. It's a proof of concept after all. I'd recommend to leave it as it is. If you need to do something
event-based or occasional (like jumping or leaning), then you can invoke the necessary animations to gets those routines working.

It's your call.

It may be useful to know that the core loop for each bot is "jv_mp_ai.scr::botcontrol".

Thanks Sor! I am putting the code exactly in that section for the leaning, jumping, and strafing in the "jv_mp_ai.scr::botcontrol" thread. Aren't the animations being called in the POC the necessary animations that I must use to get leaning, jumping, and strafing to work? Or, can I use any of the animations already in use by v1 such as the ones I listed in my previous post? My understanding is we just need to call a random animation to get leaning to work, but I'm not sure about jumping... Is there an animation for falling or jumping in v1, or am I going to have to include them somehow. Again, I'm a newb when it comes to understanding animations. These animations are declared in .tik files in which PK3? Should I not use animations for jumping? lol.... then they will look retarded, but at least they'll be jumping?